computer implemented method, computer readable storage medium and system

专利摘要:
METHOD IMPLEMENTED BY COMPUTER,COMPUTER AND SYSTEM READIBLE STORAGE MEDIA. the ways ofrealization of the present invention include receiving data fromtransaction associated with the transaction, the transaction data comprising:data representative of a plurality of assets, a firstappointment that hides a random first number and a value oftransaction transaction, a second commitment that hides a secondrandom number and a change, the transaction amount and a thirdrandom number both encrypted by a public key of the secondnode based on a homomorphic (HE) encryption schemelinear deterministic, the alteration and a fourth random number bothencrypted by a public key of the first node based on the schemelinear deterministic HE and a proof of knowledge zero (ZKP);determine, based on the ZKP, whether the transaction is valid, based on thedetermining that the first random number equals the thirdrandom number, second random number equals fourth numberrandom and the transaction amount hidden in the first commitment is equalto the transaction value encrypted by the public key of the second node.
公开号:BR112019014629A2
申请号:R112019014629-6
申请日:2018-12-21
公开日:2021-07-20
发明作者:Wenbin Zhang；Baoli Ma；Huanyu Ma
申请人:Advanced New Technologies Co., Ltd.；
IPC主号:

专利说明:

[001] [001] Trust protocol networks (blockchain), which may also be referred to as trust protocol systems, consensus networks, distributed accounting system networks, or trust protocol, allow participating entities to securely store data and immutable. A trust protocol can be described as a transaction ratio and multiple copies of the trust protocol are stored in the trust protocol network. Examples of trust protocol types can include public trust protocols, consortium trust protocols, and private trust protocols. A public trust protocol is open for all entities to use the trust protocol and participate in the consensus process. A consortium trust protocol is a trust protocol in which the consensus process is controlled by a pre-selected set from us, such as certain organizations or institutions. A private trust protocol is provided to a specific entity, which centrally controls read and write permissions.
[002] [002] Trust protocols can use different record keeping models to record transactions between users.
[003] [003] A trust protocol includes a series of blocks, each of which contains one or more transactions performed on the network. Each block can be explained by analogy to a ledger page, while the trust protocol itself is a complete copy of the ledger. Individual transactions are confirmed and added to a block, which is added to the trust protocol. Copies of the trusted protocol are replicated across network nodes. In this way, there is a global consensus on the status of the trust protocol. Furthermore, the trust protocol is open for all nodes to see, at least in the case of public networks. To protect the privacy of trusted protocol users, encryption technologies are implemented.
[004] [004] Under the account balance model, commitment schemes can be used to hide amounts that both parties to a transaction commit to. Commitment schemes can arise from the need for parties to commit to a choice or value and then later communicate that value to the other parties involved. For example, in an interactive Pedersen (PC) commitment scheme, a first user can commit to a transaction value t by sending a commitment value PC (t, r) that is generated based on the random value r. The commitment value is generated and a second user can only reveal the transaction value t by getting the random number r. To ensure that the transaction amount is valid, an interval proof can be created to prove that the transaction amount is greater than or equal to zero and less than or equal to the account balance.
[005] [005] In some cases, multiple transactions can be made from a user. As the proof of range is tied to the remaining account balance, the various transactions need to be verified sequentially in the trust protocol. As such, the corresponding interval proofs can be correctly associated with the account balances remaining after each transaction. However, checking multiple transactions sequentially can be time-consuming. A record keeping model that allows for parallel transaction checks would be beneficial, especially for time-sensitive tasks. BRIEF DESCRIPTION OF THE INVENTION
[006] [006] Embodiments of the present invention include computer-implemented methods for non-interactive privacy preservation checks of trust protocol transactions. More particularly, embodiments of the present invention are directed to a computer-implemented method capable of validating multiple transactions associated with an account of a trust protocol in parallel, based on compromise schemes and homomorphic cryptography without revealing privacy information such as amount of transactions, account balances, or random numbers to generate appointments for other trusted protocol nodes.
[007] [007] In some embodiments, the actions include receiving transaction data associated with the transaction, the transaction data comprising: data representing a plurality of assets, a first commitment that hides a first random number and a transaction amount of the transaction, a second commitment that hides a second random number and a change calculated based on deducting the transaction value from a total value of the plurality of assets, the transaction value and a third random number both encrypted by a public key of the second node based on a homomorphic encryption scheme
[008] [008] These and other embodiments may optionally include one or more of the following features: the transaction is performed between an account associated with the first node and an account associated with the second node, and the method further comprises updating, after determining that transaction is valid, first node's account and second node's account based on transaction value and modification; each of the plurality of assets is associated with one or more asset types, an asset value hidden in an appointment, and a random number used to generate the commitment; determine that each of the plurality of assets is associated with the same type of asset; the first commitment, the second commitment, and the commitment that hides the asset value are generated based on a commitment scheme that is homomorphic and in which the determination that the total value of the plurality of assets is equal to the sum of the transaction value and the alteration is carried out based on the homomorphism of the compromise scheme; the linear deterministic HE scheme is derived from a probabilistic HE scheme based on changing a random number associated with the probabilistic HE scheme to a fixed number; the ZKP comprises a compromise that hides a fifth random number and a sixth random number, a cyphertext of the fifth random number and the sixth random number encrypted by the public key of the second account based on the linear deterministic HE scheme, and a cyphertext of the fifth number random and the sixth random number encrypted by the public key of the first account, based on the linear deterministic HE scheme; the ZKP is generated and used to determine that the transaction is valid based on the properties of the linear deterministic HE; the determination that the transaction is valid is performed based on ZKP with no interactions between the first and second nodes through the trusted protocol network.
[009] [009] The present invention also provides one or more computer-readable, non-transient storage media coupled to one or more processors and having instructions stored therein which, when executed by the one or more processors, cause the one or more processors perform operations in accordance with embodiments of the methods provided herein.
[010] [010] The present invention further provides a system for carrying out the methods provided herein. The system includes one or more processors, and a computer-readable storage medium coupled to the one or more processors having instructions stored on it that, when executed by the one or more processors, cause the one or more processors to perform operations according to forms. of carrying out the methods provided here.
[011] [011] The embodiments of the matter described in this description can be implemented in order to realize particular advantages or technical effects. For example, embodiments of the present invention allow the account balance and transaction value of the trust protocol nodes to be private during transactions. The funds transfer recipient does not need to confirm the transaction or use a random number to verify an appointment; transaction validation may be non-interactive. A trust protocol node can validate the transaction based on the HE and commitment schemes to allow proof of zero knowledge.
[012] [012] The described methodology allows for the enhancement of account/data security of various mobile computer devices. Account balance and transaction amounts can be encrypted based on HE and hidden by escrow schemes. As such, a consensus node can update account balances in the ledger after the transaction based on the properties of the HE, without revealing the actual account balance. As the random number does not need to be sent to a recipient to confirm the transaction, the risk of data leakage can be reduced and less computer and memory resources need to be used to manage the random number.
[013] [013] It is appreciated that the methods in accordance with the present invention may include any combination of the aspects and features described herein. That is, the methods according to the present invention are not limited to the combinations of features and features specifically described herein, but also include any combination of the features and features provided.
[014] [014] Details of one or more embodiments of the present invention are presented in the attached Figures and in the description below. Other features and advantages of the present invention will be apparent from the description and Figures, and from the claims. BRIEF DESCRIPTION OF THE FIGURES
[015] [015] Figure 1 represents an example of an environment that can be used to perform embodiments of the present invention.
[016] [016] Figure 2 represents an example of a conceptual architecture according to embodiments of the present invention.
[017] [017] Figure 3 represents an example of a privacy-protected validation process of a trust protocol transaction based on homomorphic cryptography.
[018] [018] Figure 4 represents an example of a trust protocol transaction according to embodiments of the present invention.
[019] [019] Figure 5 represents another example of a privacy-protected validation process of a trust protocol transaction based on homomorphic cryptography.
[020] [020] Figure 6 illustrates an example of a method that can be performed according to embodiments of the present invention.
[021] [021] Figure 7 represents another example of a method that can be performed according to embodiments of the present invention.
[022] [022] Figure 8 depicts an example of a trusted protocol node that can perform a process according to embodiments of the present invention.
[023] [023] Like reference symbols in the various drawings indicate like elements. DETAILED DESCRIPTION OF THE INVENTION
[024] [024] Embodiments of the present invention include computer-implemented methods for non-interactive privacy preservation checks of trust protocol transactions.
[025] [025] To provide more context for embodiments of the present invention, and as presented above, distributed accounting systems (DLSs), which may also be referred to as consensus networks (e.g., made up of peer-to-peer nodes) , and trusted protocol networks, allow participating entities to securely and immutably conduct transactions and store data. Trust protocol is used here to refer generally to a DLS without referring to any particular use case.
[026] [026] A trust protocol is a data structure that stores transactions in a way that transactions are immutable and can be verified subsequently. A trust protocol includes one or more blocks. Each block in the chain is linked to a previous block immediately before it in the chain, including a cryptographic hash of the previous block. Each block also includes a timestamp, its own cryptographic hash, and one or more transactions. Transactions, which have already been verified by trusted protocol network nodes, are encoded and encoded in a Merkle tree. A Merkle tree is a data structure in which the data in the tree's leaf nodes is hashed and all hashes in each branch of the tree are concatenated at the root of the branch. This process continues up the tree to the root of the entire tree, which stores a hash that is representative of all the data in the tree. A hash of a supposed transaction stored in the tree can be quickly checked to determine if it is consistent with the tree structure.
[027] [027] While a trust protocol is a data structure for storing transactions, a trust protocol network is a network of computer nodes that manages, updates and maintains one or more trust protocols. As shown above, a trust protocol network can be provided as a public trust protocol network, a private trust protocol network, or a consortium trust protocol network.
[028] [028] In a publicly trusted protocol, the consensus process is controlled by nodes of the consensus network. For example, hundreds, thousands, and even millions of entities can participate in a public trust protocol, each of which operates at least one node in the public trust protocol. Thus, the public trust protocol can be considered a public network in relation to the participating entities. In some examples, most entities (nodes) must sign all blocks for the block to be valid and added to the trust protocol. Examples of public trust protocol networks include private peer-to-peer payment networks that use a distributed ledger known as a trust protocol. As noted above, the term trusted protocol, however, is used to refer generally to distributed ledgers without particular reference to any particular trusted protocol network.
[029] [029] In general, a public trust protocol supports public transactions. A public transaction is shared with all nodes within the trust protocol, and the trust protocol is replicated across all nodes. In other words, all nodes are in a perfect state of consensus regarding the trust protocol. To reach consensus (eg, agreement to add a block to a trusted protocol), a consensus protocol is implemented within the trusted protocol network.
[030] [030] Embodiments of the present invention include computer-implemented methods for non-interactive privacy preservation checks of trust protocol transactions. More particularly, embodiments of the present invention are directed to a computer-implemented method capable of validating multiple transactions associated with an account of a trust protocol in parallel, based on compromise schemes and homomorphic cryptography without revealing privacy information such as amount of transactions, account balances, or random numbers to generate appointments for other trusted protocol nodes.
[031] [031] According to embodiments of the present invention, trust protocol nodes can use a generic account model that can support parallel transaction checks as a method of record keeping. In comparison to the account balance model, trust protocol nodes that adopt the generic account model can keep records of a plurality of assets rather than account balances. Each of the plurality of assets can be associated with at least one of an asset type, an asset ID, or an asset value. Asset under the generic account model can be in any form or type, such as cash or fixed. Monetary assets can include real currency or cryptocurrency. In some embodiments, fixed assets can be converted to monetary assets associated with a monetary value. The monetary value can then be used to carry out transactions between accounts in a trusted protocol network. For purposes of illustration, it is assumed that the assets described in the embodiments of the present invention are converted to the same currency type and saved in trust protocol accounts in the generic account template.
[032] [032] To protect data privacy, transactions can be recorded in a trust protocol (ledger) based on the commitment, without disclosing the transaction amount or monetary value information associated with the protocol's user accounts. confidence. A commitment scheme can be used to generate a commitment of a transaction amount using a random number. An example engagement scheme includes, without limitation, the PC scheme. Since the transaction amount is hidden in the commitment, one or more range tests can be used to prove that the transaction amount does not exceed the trust protocol user account value.
[033] [033] In the account balance template, interval proofs are associated with the account balance. If more than one transaction is made, but not all transactions are validated and recorded in the trust protocol, interval proofs may be associated with incorrect account balances and therefore may be invalid. In comparison, under the generic account model, the account value can be calculated as the sum of a plurality of assets. When a transaction amount is to be transferred between trust protocol user accounts, at least a portion of the plurality of assets with a combined value greater than or equal to the transaction amount can be used to cover the transaction amount. additional transfers can be made under the condition that the remaining assets have a combined value greater than the amount to be transferred. Even if transactions are not validated and recorded in the trust protocol, interval proofs that show that the combined value of the remaining assets is greater than or equal to the transaction value may still be valid. Therefore, more than one transaction check can be performed in parallel in the generic account model.
[034] [034] According to the embodiments of the present invention, trust protocol transactions can be validated and recorded in a trust protocol (ledger) based on commitment, without revealing the transaction account balance, the transaction amount or the random number used to generate the commitment. A commitment scheme, such as the PC scheme, can be used to generate a commitment of a transaction amount based on a random number. The transaction amount and random number can be encrypted using either probabilistic or linear deterministic HE. The transaction amount and random number can also be used to generate a set of values like ZKP to validate the transaction based on the properties of the HE schema used. Transaction value compromise, encrypted transaction value and encrypted random number and ZKP can be used by a trusted protocol node to verify that the transaction is valid without the account balances, transaction value or number random being revealed.
[035] [035] Figure 1 represents an example of an environment (100) that can be used to perform embodiments of the present invention. In some examples, the example environment (100) allows entities to participate in a public trust protocol (102). The example environment (100) includes computing systems (106, 108) and a network (110).
[036] [036] In the example described, computing systems (106,
[037] [037] Figure 2 represents an example of a conceptual architecture (200) according to embodiments of the present invention. The exemplary conceptual architecture (200) includes an entity layer (202), a hosted services layer (204), and a public trust protocol layer (206). In the example shown, the entity layer (202) includes three entities, Entity_1 (E1), Entity_2 (E2) and Entity_3 (E3), each entity having a respective transaction management system (208).
[038] [038] In the illustrated example, the hosted services layer (204) includes trusted protocol interfaces (210) for each transaction management system (208). In some examples, a respective transaction management system (208) communicates with a respective trusted protocol interface (210) over a network (e.g., the network (110) of Figure 1) using a communication protocol ( for example, secure hypertext transfer protocol (HTTPS)). In some examples, each trusted protocol interface (210) provides a communication link between a respective transaction management system (208) and the trusted protocol layer (206). More particularly, each trust protocol interface (210) allows the respective entity to perform transactions recorded in a trust protocol network (212) of the trust protocol layer (206). In some examples, communication between a trusted protocol interface (210), and the trusted protocol layer (206) is conducted using remote procedure calls (RPCs). In some examples, trust protocol interfaces (210) “host” trust protocol nodes to respective transaction management systems (208). For example, the trust protocol interfaces (210) provide the application programming interface (API) for accessing the trust protocol network (212).
[039] [039] As described here, the Trusted Protocol Network (212) is provided as a peer-to-peer network including a plurality of nodes (214) that immutably record information in a Trusted Protocol (216). Although a single trust protocol (216) is schematically represented, multiple copies of the trust protocol (216) are provided, and are maintained across the trust protocol network (212). For example, each node (214) stores a copy of the trusted protocol (216). In some embodiments, the trust protocol
[040] [040] Figure 3 represents an example of a privacy-protected validation process (300) of a trust protocol transaction based on HE. At a high level, the example process (300) is performed by a user node A (302), a user node B (not shown in Figure 3), and a trust protocol node (304), also referred to as a consensus node. Both user A's node account (302) and user B's node account can have a record keeping template based on a generic account template. That is, the account records of user A's node (302) and user B's node are maintained as a plurality of assets. A transaction, such as a transfer of value, can be made from user node A (302) to user node B. User node A (302) can select one or more account assets that have a greater total value or equal to the transaction amount to cover the transaction. The difference between a total value of one or more assets and the transaction value can be considered as the transaction change left to user node A (302).
[041] [041] To protect the privacy of the account, user node A (302) may generate asset value commitments used to cover the transaction. User node A (302) may also generate a transaction transaction value commitment. User node A (302) can also use HE to encrypt the transaction amount, change and random numbers used to generate the appointments. To check the validity of the transaction, the trust protocol node (304) can compare the transaction amount, change and random numbers hidden in appointments and encrypted by HE based on a ZKP. If the transaction amount, change, and random numbers match, the transaction is determined to be valid by the trust protocol node (304). More details of the process (300) are discussed in the following description of Figure 3.
[042] [042] At (306), user node A (302) selects a plurality of assets to transfer a transaction amount to user node B. User node A (302) and user node B can be trust protocol consensus nodes or user nodes that use the trust protocol network without participating in the consensus process. As discussed earlier, user node A (302) can use a generic account template to maintain records. Rather than keeping the account balance for recording in the account balance template, the account value of user A's node (302) is measured by the total value of the assets it owns. User node A (302) can select a plurality of assets that have sufficient value to cover the transaction value. For example, if the transaction amount is 7.5 US dollars, user node A (302) can select three assets that are worth 5, 2, and 1 US dollar, respectively, to cover the transaction amount.
[043] [043] In some embodiments, each asset may be associated with a transaction address or asset ID that identifies the corresponding asset. The asset ID can be the asset information hash. Asset IDs of selected assets k can be represented as ID1, ..., IDk.
[044] [044] At (308), user node A (302) calculates a change based on a total value of the plurality of assets and the transaction value.
[045] [045] In (310), user node A (302) generates a random number corresponding to the transaction amount and a random number corresponding to the change. The random number corresponding to the transaction amount t can be denoted as r. The random number corresponding to change t0 can be denoted r0. In some embodiments, a plurality of random numbers can be generated to produce asset value tradeoffs. For example, suppose a1, ..., ak are asset values, random numbers that correspond to asset values can be expressed as ra1, …, rak.
[046] [046] In some embodiments, the random number r0 can be calculated rather than randomly generated. The calculation can be expressed as r0 = ra1 + ... + rak - r, where r is the random number generated to produce the commitment for the transaction amount t. Using the calculated random number r0, user node A (302) does not need to generate an additional ZKP to prove that the total value of transferred assets is equal to the total value of assets received. In some embodiments, another random number r’ can be calculated as r' = r1 +… + rk - r - r0, to help with ZKP.
[047] [047] In (312), user node A (302) generates transaction value and change commitments, and encrypts the corresponding random numbers based on probabilistic HE. In some embodiments, homomorphic compromise schemes such as PC can be used to generate the compromises. Using PC as a non-limiting example, the PC of transaction value t can be generated using the random number r, which can be expressed as PC(r,t) = grht, where g and h can be generators of an elliptic curve, and PC(r,t) is a scalar multiplication of curve points. Similarly, the PC of change t0 can be expressed as PC (r0, t0) = gr0ht0.
[048] [048] Random number r can be encrypted using the public key of user node B based on a probabilistic HE scheme, such as an Okamoto-Uchiyama (OU) encryption scheme. It is to be understood that other HE schemes, such as Boneh-Goh-Nissim, can also be used. Using OR as a non-limiting example, the random number can be encrypted based on the OR by treating the transaction value t as a random number, which can be expressed as OUB(r,t) = urvt or simply OUB(t) where u is a generator of (Z/nZ)* satisfying the conditions that v = un mode n, and n = p × q, where p and q are two prime numbers. Probabilistic OR can satisfy the property that OR (a + b) = OR (a) × OR (b), where a and b are the plain text used for OR.
[049] [049] Random number r0 can be encrypted using the public key of user node A (302). The random number can be encrypted based on the OR by treating the t0 change as a random number, which can be expressed as OUA (r0, t0).
[050] [050] The transaction value cyphertext can then be expressed as t = (PC (t, r), OUB (r, t)), and the change cyphertext can then be expressed as t0 = (PC (t0, r0) , OR (r0, t0)). Similarly, the cyphertext of the selected active k can be expressed as ti = (PC (ti, ri), OUA (ri, ti)), where i = 1, ... k.
[051] [051] In (314), user node A (302) generates one or more interval proofs. In some embodiments, a first interval proof, RP1, can be generated to show that transaction t ≥ 0. A second interval proof, RP2, can be generated to show that the change t0 ≥ 0, or in other words , the total The value of the plurality of assets is greater than or equal to the transaction value.
[052] [052] At (316), user node A (302) generates a ZKP. ZKP can be used to show that the random number and hidden transaction value in PC(r,t) is the same as the random number and encrypted transaction value in OUB(r,t), and the random number and the transaction The hidden value in the PC (r0, t0) is the same as the random number and encrypted transaction value in the OUA (r0, t0). To generate the ZKP, two random numbers, t’1 and r’1, can be selected. The two random numbers can be used to generate three values, which are P = PC (t'1, r'1), P' =OUB (r'1, t'1), P'' =OUA (r'1 , t1). The three values can then be used to generate a hash expressed as x = Hash (P, P’, P’’). the hash value x can be used to calculate t'2 = t'1 + xt, r'2 = r'1 + xr, t'3 = t'1 + xt and r'3 = r'1 + xr0. The ZKP can then be expressed as (P, P’, t'2, r'2, P’’, t'3, r'3).
[053] [053] At (318), user node A (302) uses a private key to generate a digital signature to sign transaction data. In some embodiments, the transaction data may include the asset IDs of the selected k assets (ID1, ..., IDk), the transaction value cyphertext (T), the change cyphertext (T0), the proofs interval (RP1 and RP2), the random number r' and the ZKP.
[054] [054] At (320), user node A (302) sends the digitally signed copy of the transaction data to a trusted protocol network.
[055] [055] At (322), the trust protocol node (304) verifies the digital signature. Digital signature verification can be performed to ensure that transaction data is sent by user node A (302).
[056] [056] At (324), the trust protocol node (304) verifies that the selected assets are associated with user node A's account. The verification can be based on the asset IDs of the assets.
[057] [057] At (326), the trust protocol node (304) verifies that the total value of the selected plurality of assets is equal to the sum of the transaction amount and the change amount. In other words, the trust protocol verifies that a1 + ... + ak = t + t0 As discussed earlier, under the generic account model, assets can be held in the trust protocol like PCs to protect data privacy. Based on the homomorphism of PC, PC (ra1, a1) ×... × PC (rak, ak) = PC (ra1 + ... + rak, a1 + ... + ak) and PC (r, t) × PC (r0, t0) = PC (r + r0, t + t0). Therefore, showing that PC (ra1, a1) ×...
[058] [058] At (328), the trust protocol node (304) checks for one or more range probes.
[059] [059] At (330), the trust protocol node (304) checks the ZKP. As discussed above, ZKP can be generated to check whether the random number corresponding to the transaction value encrypted using the user node B's public key is the same as the corresponding random number hidden by the PC, and whether the random number corresponding to the change encrypted using the public key of user node A (302) is the same as the corresponding random number hidden by the PC. In some embodiments, to verify the ZKP, the trust protocol node (304) may first compute the hash value x as x = Hash (P, P’, P’’). The trust protocol node (304) can then check whether PC(t'2, r'2) = P × PC(t, r) x, OUB (r'2, t'2) = P' × OUB ( r, t) x, CP (t'3, r'3) = P x CP (t0, r0) x and OUA (r'3, t'3) = P' ' × OUA (r0, t0) x are all true. If all are true, the example process (300) proceeds to (332). Otherwise, the trusting protocol node (304) may reject the transaction.
[060] [060] At (332), the trust protocol node (304) updates user node A (302) and user node B accounts. user B maintains assets as records in the generic account template, after the transaction, the plurality of assets transferred from user A's node (302) can be removed from user A's node account (302). The change can be added back to user A's node account (302). The transaction amount and the corresponding asset ID can be added as a new resource to user B's node account. In some embodiments, the update can be performed based on updating asset lists maintained by the corresponding node accounts. of user A (302) and user node B. In some embodiments, the Update can be performed based on adding transaction value cyphertexts and changing the encrypted asset values held by user node A ( 302) and by user node B. Updating accounts is described in more detail here with reference to Figure 4.
[061] [061] Figure 4 illustrates an example of a transaction (400) trust protocol according to embodiments of the present invention. As shown in the example trust protocol transaction (400), a user node A (402) transfers a transaction value t to a user node B (404). Before the transaction, user node A (402) has n assets including (ID1, t1, ID2, t2), (IDn, tn).
[062] [062] Using the commitment schemes, encryption schemes, and transaction process described here with reference to Figure 3 as an example, user node A (402) can generate the transaction data (408), which can include transaction IDs. assets of the selected k assets, ID, ID2,… IDk. Transaction data (408) may further include t0, t, RP1, RP2, r’ and the ZKP. After the transaction data (408) is generated, user node A (402) can add its digital signature and submit the digitally signed transaction data to the trust protocol network (406) for consensus.
[063] [063] After the transaction, the selected k assets can be removed from user A's asset account (402). The change can be added back to user node A (402). Therefore, user node A (402) can have the following resources expressed as (IDk +(1), tk + (1), IDk + (2), tk + (2)), …, (IDn, tn, ID0, t0) where ID0 represents the asset ID of change t0.
[064] [064] Before the transaction, user node B (404) has m assets, which can be expressed as (ID1’, t1’, ID2’, t2’, IDm’, tm’). After the transaction, the transaction amount can be added to user node B (404).
[065] [065] Figure 5 represents an example of a process (500) of validation protected by privacy of a trust protocol transaction based on HE. At a high level, the example process (500) is performed by a user node A (502), a user node B (not shown in Figure 5) and a trust protocol node (504), also referred to as a consensus node. User A's node account (502) and user B's node account can be based on a generic account template. A transaction, such as a transfer of value, can be done from user node A (502) to user node B. User node A (502) can select one or more account assets that have a greater total value or equal to the transaction amount to cover the transaction. The difference between the total value of one or more assets and the transaction value can be considered as the transaction change left to user node A (502).
[066] [066] To protect the privacy of the account, user node A (502) can generate commitments for the asset values used to cover the transaction and the transaction value using a commitment scheme such as the PC. User node A (502) can also use linear deterministic HE to encrypt random numbers used to generate the appointments. The linear deterministic HE can have the following properties: HE (s + t) = HE (s) × HE (t) and HE (kt) = HE (t) k. To check the validity of the transaction, the trust protocol node (504) can compare the HE-encrypted and hidden random numbers based on a ZKP. If the random numbers match, the transaction can be determined to be valid by the trusting protocol node (504). More details of the process example (500) are discussed in the following description of Figure 5.
[067] [067] At (506), user node A (502) selects a plurality of assets to transfer a transaction amount to user node B. User node A (502) and user node B can be the trust protocol consensus node or user nodes that use the trust protocol network without participating in the consensus process. User node A (502) can select a plurality of assets that have sufficient value to cover the transaction value.
[068] [068] In some embodiments, each asset may be associated with a transaction address or asset ID that identifies the corresponding asset. The asset ID can be the asset information hash. Asset IDs of selected assets k can be represented as ID1, ..., IDk.
[069] [069] At (508), user node A (502) calculates a change based on a total value of the plurality of assets and the transaction value.
[070] [070] In (510), the user node A (502) generates a random number corresponding to the transaction amount and a random number corresponding to the change. The random number corresponding to the transaction amount t can be denoted as r. The random number corresponding to change t0 can be denoted r0. In some embodiments, a plurality of random numbers can be generated to produce asset value tradeoffs. For example, suppose a1, ..., ak are asset values, random numbers that correspond to asset values can be expressed as ra1, …, rak.
[071] [071] In some embodiments, the random number r0 may be calculated rather than randomly generated. The calculation can be expressed as r0 = ra1 + ... + rak - r, where r is the random number generated to produce the commitment for the transaction amount t. When calculating r0, user node A (502) does not need to generate an additional ZKP to show that the total value of assets transferred is equal to the total value of assets received. In some embodiments, a random number r’ can be calculated as r’ = r1 +... + rk - r - r0.
[072] [072] In (512), user node A (502) generates transaction value and change commitments, and encrypts the corresponding random numbers based on deterministic HE. In some embodiments, homomorphic compromise schemes such as PC can be used to generate the compromises. Using PC as a non-limiting example, the PC of transaction value t can be generated using the random number r, which can be expressed as PC(r,t) = grht, where g and h can be generators of an elliptic curve, and PC(r,t) is a scalar multiplication of curve points. Similarly, the PC of change t0 can be expressed as PC (r0, t0) = gr0ht0.
[073] [073] The random number r can be encrypted using the public key of user node B based on linear deterministic HE. Linear deterministic HE can be obtained from probabilistic HE, such as Paillier, Benaloh, OR, Naccache-Stern, Boneh-Goh-Nissim, Damgard-Jurik, or equal-probability HE, setting the random number in the HE scheme to 0 or (1) or another appropriate number. The encrypted random number can be expressed as HE(r).
[074] [074] The random number r0 can be encrypted using the public key of user node A. The random number can be encrypted based on linear deterministic HE. The encrypted random number can be expressed as HE (r0).
[075] [075] The cyphertext of the transaction value t can then be expressed as t = (grht, HEB (r)), and the cyphertext of the change can be expressed as t0 = (gr0ht0, HEA (r0)). Similarly, the cyphertext of the selected active k can be expressed as ti = (grihti, HE (ri), where i = 1, ..., k.
[076] [076] In (514), user node A (502) generates one or more interval proofs. In some embodiments, a first interval proof, RP1, can be generated to show that transaction t ≥ 0. A second interval proof, RP2, can be generated to show that the change t0 ≥ 0, or in other words , the total The value of the plurality of assets is greater than or equal to the transaction value.
[077] [077] At (516), user node A (502) generates a ZKP. ZKP can be used to show that the hidden random number in PC (r,t) is the same as the encrypted random number in HE (r), and the hidden random number in PC (r0,t0) is the same as the random number encrypted in HE (r0). To generate the ZKP, two random numbers, t1 and r1, can be selected. The two random numbers can be used to generate three values, which are P = gr'1ht'1, P’ = HEB (r'1), P’’ = HEA (r'1). The three values can then be used to generate a hash expressed as x = Hash (P, P’,
[078] [078] At (518), user node A (502) uses a private key to generate a digital signature to sign transaction data. In some embodiments, the transaction data may include the asset IDs of the selected k assets (ID1, ..., IDk), the transaction value cyphertext (T), the change cyphertext (T0), the proofs interval (RP1 and RP2), the random number r' and the ZKP.
[079] [079] At (520), user node A (502) sends the digitally signed copy of the transaction data to a trusted protocol network.
[080] [080] At (522), the trust protocol node (504) verifies the digital signature. Digital signature verification can be performed to ensure that transaction data is sent by user node A (502). In some embodiments, the trust protocol node (504) includes an anti-double spend mechanism that can check whether the transaction has already been executed. If so, the trusting protocol node (504) can reject the transaction.
[081] [081] In (524), the trust protocol node (504) verifies that the selected assets are associated with user node A's account. The verification can be based on the asset IDs of the assets.
[082] [082] At (526), the trust protocol node (504) verifies that the total value of the selected plurality of assets is equal to the sum of the transaction value and the change. In other words, the trust protocol node (504) verifies that a1 + ... + ak = t + t0 As discussed earlier, under the generic account model, assets can be held in the trust protocol as PCs to protect data privacy. Based on the homomorphism of PC, PC (ra1, a1) ×... × PC (rak, ak) = PC (ra1 + ... + rak, a1
[083] [083] At (528), the trust protocol node (504) checks for one or more range probes.
[084] [084] At (530), the trust protocol node (504) checks the ZKP. As discussed earlier, ZKP can be generated to check whether the random number corresponding to the transaction value encrypted using the user node B's public key is the same as the corresponding random number hidden by the PC, and whether the random number corresponding to the a change encrypted using the public key of user node A (502) is the same as the corresponding random number hidden by the PC. In some embodiments, to verify the ZKP, the trust protocol node (504) may first compute the hash value x as x = Hash (P, P’, P’’). The trust protocol node (504) can then verify that gr'2ht'2 = P × (grht) x, HEB (r') = P' × HE (r) x, gr'3ht'3 = P × ( gr0ht0) x, and HEA (r'3) = P' ' × HEA (r0) x are all true. If each is true, the example process (500) proceeds to (532). Otherwise, the trusting protocol node (504) may reject the transaction.
[085] [085] At (532), the trust protocol node (504) updates the accounts of user node A (502) and user node B. As the accounts of user node A (502) and node of user B maintains assets as records in the generic account template, after the transaction, the plurality of assets transferred from user A's node (502) can be removed from user A's node account (502). The change can be added back to user A's node account (502). The transaction amount and the corresponding asset ID can be added as a new resource to user B's node account. In some embodiments, the update can be performed based on updating asset lists maintained by the corresponding node accounts. of user A (502) and user node B. In some embodiments, the Update can be performed based on adding transaction value cyphertexts and changing the encrypted asset values held by user node A ( 502) and by user node B. An example trust protocol transaction (400) and the corresponding account updates are described in the description in Figure 4.
[086] [086] Figure 6 illustrates an example of a process (600) that can be performed according to embodiments of the present invention.
[087] [087] At (602), a consensus node receives transaction data associated with the transaction. In some examples, transaction data comprises data representative of a plurality of assets, a first commitment that hides a first random number and a transaction transaction amount, a second commitment that hides a second random number, and a calculated change based on the deducting the transaction value from a total value of the plurality of assets, the transaction value and a third random number both encrypted by a public key of the second node based on a probabilistic HE scheme, the alteration and a fourth random number encrypted by a public key of the first node based on the probabilistic HE scheme, one or more interval proofs, a
[088] [088] In some embodiments, each of the plurality of assets is associated with one or more asset types, a hidden asset value in an appointment, and a random number used to generate the appointment. In some embodiments, the consensus node determines that each of the plurality of assets is associated with the same asset type. In some embodiments, the first commitment, the second commitment, and the commitment that hides the asset value are generated based on a commitment scheme that is homomorphic.
[089] [089] In some embodiments, the third random number is encrypted based on the probabilistic HE scheme, treating the transaction amount as a random number, and the fourth random number is encrypted based on the probabilistic HE scheme, treating the change as a random number. In some embodiments, the first compromise and second compromise are generated based on a Pedersen compromise scheme, and the HE probabilistic scheme is an OU encryption scheme.
[090] [090] In some embodiments, the ZKP comprises a Pedersen compromise that hides a fifth random number and a sixth random number, a cyphertext of the fifth random number and the sixth random number encrypted by the public key of the second account based on the scheme of OU encryption, and a cyphertext of the fifth random number and the sixth random number encrypted by the public key of the first account based on the OU encryption scheme.
[091] [091] At (604), the consensus node verifies the digital signature based on the public key of the first node.
[092] [092] In (606), the consensus node determines that one or more interval proofs prove that the transaction amount and change are greater than or equal to zero.
[093] [093] At (608), the consensus node determines that the total value of the plurality of notes is equal to the sum of the transaction and change value. In some embodiments, the determination that the total value of the plurality of assets is equal to the sum of the transaction value and the change is made based on the homomorphism of the commitment scheme.
[094] [094] In (610), the consensus node determines, based on the ZKP, that the transaction is valid by determining that the first random number equals the third random number, the second random number equals the fourth random number and the transaction value hidden in the first appointment is equal to the transaction value encrypted by the public key of the second node.
[095] [095] In some embodiments, the transaction is executed between an account associated with the first node and an account associated with the second node, and the method further comprises updating, after determining that the transaction is valid, the account associated with the first node and the account associated with the second node based on transaction amount and change. In some embodiments, the ZKP is generated and used to determine that the transaction is valid based on the properties of the probabilistic HE. In some embodiments, the determination that the transaction is valid is performed based on the ZKP with no interactions between the first and second nodes over the trust protocol network.
[096] [096] Figure 7 represents an example of a process (700) that can be performed according to embodiments of the present invention.
[097] [097] At (702), a consensus node receives transaction data associated with the transaction. In some examples, transaction data comprises data representative of a plurality of assets, a first commitment that hides a first random number and a transaction transaction amount, a second commitment that hides a second random number, and a calculated change based on the deduction of the transaction value from a total value of the plurality of assets, the transaction value and a third random number both encrypted by a public key of the second node based on a linear deterministic HE scheme, the alteration and a fourth encrypted random number by a public key of the first node based on the linear deterministic HE scheme, one or more range proofs, a ZKP and a digital signature generated based on a private key that matches the public key of the first node.
[098] [098] In some embodiments, each of the plurality of assets is associated with one or more asset types, a hidden asset value in an appointment, and a random number used to generate the commitment. In some embodiments, the consensus node determines that each of the plurality of assets is associated with the same asset type. In some embodiments, the first commitment, the second commitment, and the commitment that hides the asset value are generated based on a commitment scheme that is homomorphic.
[099] [099] In some embodiments, the linear deterministic HE scheme is derived from a probabilistic HE scheme based on changing a random number associated with the HE probabilistic scheme to a fixed number.
[0100] [0100] In some embodiments, the ZKP comprises a compromise that hides a fifth random number and a sixth random number, a cyphertext of the fifth random number and the sixth random number encrypted by the public key of the second account based on the HE scheme linear deterministic, and a cyphertext of the fifth random number and the sixth random number encrypted by the public key of the first account based on the linear deterministic HE scheme.
[0101] [0101] At (704) the consensus node verifies the digital signature based on the public key of the first node.
[0102] [0102] In (706), the consensus node determines that one or more interval proofs prove that the transaction amount and change are each greater than or equal to zero.
[0103] [0103] In (708), the consensus node determines that the total value of the plurality of notes is equal to the sum of the transaction and change value. In some embodiments, the determination that the total value of the plurality of assets is equal to the sum of the transaction value and the change is made based on the homomorphism of the commitment scheme.
[0104] [0104] In (710), the consensus node determines, based on the ZKP, that the transaction is valid by determining that the first random number equals the third random number, the second random number equals the fourth random number and the transaction value hidden in the first appointment is equal to the transaction value encrypted by the public key of the second node.
[0105] [0105] In some embodiments, the transaction is executed between an account associated with the first node and an account associated with the second node, and the method further comprises updating, after determining that the transaction is valid, the account associated with the first node and the account associated with the second node based on transaction amount and change. In some embodiments, the ZKP is generated and used to determine that the transaction is valid based on the properties of the linear deterministic HE. In some embodiments, the determination that the transaction is valid is performed based on the ZKP with no interactions between the first and second nodes over the trust protocol network.
[0106] [0106] Figure 8 represents an example of a trusted protocol node (800) that can perform a process according to embodiments of the present invention. At a high level, the trust protocol node (800) includes a receiver unit (802), a verification unit (804), a first determination unit (806), a second determination unit (808) and a third unit of determination (810).
[0107] [0107] In some embodiments, the receiving unit (802) is operable to receive transaction data associated with the transaction. In some examples, transaction data comprises data representative of a plurality of assets, a first commitment that hides a first random number and a transaction transaction amount, a second commitment that hides a second random number, and a calculated change based on the deducting the transaction value from a total value of the plurality of assets, the transaction value and a third random number both encrypted by a public key of the second node based on a probabilistic HE scheme, the alteration and a fourth random number encrypted by a public key of the first node based on the probabilistic HE scheme, one or more range proofs, a ZKP and a digital signature generated based on a private key that matches the public key of the first node.
[0108] [0108] In some embodiments, the receiving unit
[0109] [0109] In some embodiments, each of the plurality of assets is associated with one or more asset types, an asset value hidden in an appointment, and a random number used to generate the appointment. In some embodiments, the trust protocol node (800) determines that each of the plurality of assets is associated with the same asset type. In some embodiments, the first commitment, the second commitment, and the commitment that hides the asset value are generated based on a commitment scheme that is homomorphic. In some embodiments, the linear deterministic HE scheme is derived from a probabilistic HE scheme based on changing a random number associated with the probabilistic HE scheme to a fixed number.
[0110] [0110] In some embodiments, the third random number is encrypted based on the probabilistic HE scheme, treating the transaction amount as a random number, and the fourth random number is encrypted based on the probabilistic HE scheme, treating the change as a random number. In some embodiments, the first compromise and second compromise are generated based on a Pedersen compromise scheme, and the HE probabilistic scheme is an OU encryption scheme.
[0111] [0111] In some embodiments, the ZKP comprises a Pedersen compromise that hides a fifth random number and a sixth random number, a cyphertext of the fifth random number and the sixth random number encrypted by the public key of the second account based on the scheme of OU encryption, and a cyphertext of the fifth random number and the sixth random number encrypted by the public key of the first account based on the OU encryption scheme. In some embodiments, the ZKP comprises a compromise that hides a fifth random number and a sixth random number, a cyphertext of the fifth random number and the sixth random number encrypted by the public key of the second account based on the linear deterministic HE scheme, and a cyphertext of the fifth random number and the sixth random number encrypted by the public key of the first account based on the linear deterministic HE scheme.
[0112] [0112] The verification unit (804) is operable to verify the digital signature based on the public key of the first node.
[0113] [0113] The first determination unit (806) is operable to determine one or more range proofs that prove that the transaction amount and the change are each greater than or equal to zero.
[0114] [0114] The second determination unit (808) is operable to determine that the total value of the plurality of notes is equal to the sum of the transaction value and the change. In some embodiments, the determination that the total value of the plurality of assets is equal to the sum of the transaction value and the change is made based on the homomorphism of the commitment scheme.
[0115] [0115] The third determination unit (810) is operable to determine, based on the ZKP, that the transaction is valid by determining that the first random number equals the third random number, the second random number equals the fourth random number and the transaction amount hidden in the first appointment is equal to the transaction value encrypted by the public key of the second node.
[0116] [0116] In some embodiments, the transaction is performed between an account associated with the first node and an account associated with the second node, and the trust protocol node (800) may include an operable update unit to update, after the third determination unit (810) determines that the transaction is valid, the account associated with the first node and the account associated with the second node based on the transaction amount and the change. In some embodiments, the ZKP is generated and used to determine that the transaction is valid based on the properties of the probabilistic HE. In some embodiments, the ZKP is generated and used to determine that the transaction is valid based on the properties of the linear deterministic HE. In some embodiments, the determination that the transaction is valid is performed based on the ZKP with no interactions between the first and second nodes over the trust protocol network.
[0117] [0117] The embodiments of the subject matter described in this descriptive report can be implemented in order to achieve particular advantages or technical effects. For example, embodiments of the present invention allow the account balance and transaction value of the trust protocol nodes to be private during transactions. The funds transfer recipient does not need to confirm the transaction or use a random number to verify a commitment, transaction validation may be non-interactive. A trust protocol node can validate the transaction based on the HE and commitment schemes to allow proof of zero knowledge.
[0118] [0118] The described methodology allows for the improvement of account/data security of various mobile computing devices. Account balance and transaction amounts can be encrypted based on HE and hidden by compromise schemes. As such, a consensus node can update account balances in the ledger after the transaction based on the properties of the HE, without revealing the account's actual account balance. As the random number does not need to be sent to a recipient to confirm the transaction, the risk of data leakage can be reduced and less computing and memory resources need to be used to manage the random number.
[0119] [0119] The embodiments and operations described in this descriptive report can be implemented in digital electronic circuits, or in computer software, firmware or hardware, including the structures disclosed in this descriptive report or in combinations of one or more of them. Operations may be implemented as operations performed by a data processing apparatus on data stored on one or more computer readable storage devices or received from other sources. A data processing apparatus, computer or computing device may encompass data processing apparatus, devices and machines, including, for example, a programmable processor, a computer, a system on a chip, or various or combinations of the foregoing. The apparatus may include special purpose logic circuitry, for example, a central processing unit (CPU), a field-programmable gate network (FPGA), or an application-specific integrated circuit (ASIC). The apparatus may also include code that creates an execution environment for the computer program in question, e.g., code that constitutes processor firmware, a protocol stack, a database management system, an operating system (e.g. , an operating system or a combination of operating systems), a cross-platform runtime environment, a virtual machine, or a combination of one or more of them. The appliance and execution environment can realize various infrastructures of different computing models, such as web services, distributed computing infrastructures, and grid computing infrastructures.
[0120] [0120] A computer program (also known, for example, as a program, software, software application, software module, software unit, script, or code) may be written in any form of programming language, including compiled languages or interpreted, declarative or procedural languages, and can be implemented in any form, including as a stand-alone program or as a module, component, subroutine, object, or other unit suitable for use in a computing environment. A program can be stored in a part of a file that contains other programs or data (for example, one or more scripts stored in a markup language document), in a single file dedicated to the program in question, or in several coordinated files ( for example, files that store one or more modules, subprograms, or pieces of code). A computer program can run on one computer or on several computers that are located in one location or distributed in multiple locations and interconnected by a communication network.
[0121] [0121] Processors for executing a computer program include, by way of example, general and special purpose microprocessors, and any one or more processors of any type of digital computer. Generally speaking, a processor will receive instructions and data from read-only memory or random access memory, or both. The essential elements of a computer are a processor to perform actions according to instructions and one or more memory devices to store instructions and data. Generally speaking, a computer will also include, or be operatively coupled to receive data from or transfer data to, or both, one or more mass storage devices for storing data. A computer can be embedded in another device, for example, a mobile device, a personal digital assistant (PDA), a game console, a Global Positioning System (GPS) receiver or a portable storage device. Devices suitable for storing computer program instructions and data include non-volatile memory, memory media and devices, including, by way of example, semiconductor memory devices, magnetic disks, and magneto-optical disks. Processor and memory can be supplemented by, or incorporated into, special purpose logic circuitry.
[0122] [0122] Mobile devices may include handsets, user equipment (EU), mobile phones (eg smart phones), tablets, wearable devices (eg smart watches and smart glasses), devices implemented within the human body (by biosensors, cochlear implants) or other types of mobile devices. Mobile devices can communicate wirelessly (for example, using radio frequency (RF) signals) to various communication networks (described below). Mobile devices can include sensors to determine characteristics of the mobile device's current environment. Sensors can include cameras, microphones, proximity sensors, GPS sensors, motion sensors, accelerometers, ambient light sensors, humidity sensors, gyroscopes, compasses, barometers, fingerprint sensors, facial recognition systems, RF sensors ( eg Wi-Fi and cellular radio), thermal sensors or other types of sensors. For example, cameras can include a forward-facing or backward-facing camera with moving or fixed lenses, a flash, an image sensor, and an image processor. The camera may be a megapixel camera capable of capturing details for facial and/or iris recognition. The camera, together with a data processor and authentication information stored in memory or accessed remotely, can form a facial recognition system. The facial recognition system or one or more sensors, eg microphones, motion sensors, accelerometers, GPS sensors or RF sensors, can be used for user authentication.
[0123] [0123] To provide interaction with a user, embodiments can be implemented on a computer with a display device and a data input device, for example, a liquid crystal display (LCD) or organic emitting diode display of light (OLED) / virtual reality (VR) / augmented reality (AR) to display information to the user, and a touch-sensitive screen, keyboard, and pointing device by which the user can provide input to the computer. Other types of devices can also be used to provide interaction with a user; for example, the feedback provided to the user may be any form of sensory feedback, for example, visual feedback, auditory feedback or tactile feedback; and user input can be received in any form, including acoustic, speech or tactile input. In addition, a computer can interact with a user by sending documents to and receiving documents from a device that is used by the user; for example, sending web pages to a web browser on a user's client device in response to requests received from the web browser.
[0124] [0124] Embodiments may be implemented using computing devices interconnected by any form or means of wired or wireless digital data communication (or combination thereof), for example, a communication network. Examples of interconnected devices are a generally remote client and server that typically interact over a communication network. A customer, for example, a mobile device, can carry out transactions itself, with a server or through a server, for example, carrying out purchase, sale, payment, delivery, shipment or loan transactions, or by authorizing them. Such transactions can be real-time, so that an action and a response are temporarily close together; for example, an individual perceives the action and the response occurring substantially simultaneously, the time difference for a response after the individual's action is less than 1 millisecond (ms) or less than 1 second (s), or the response is without delay intentional, considering the processing limitations of the system.
[0125] [0125] Examples of communication networks include a local area network (LAN), a radio access network (RAN), a metropolitan area network (MAN) and a wide area network (WAN). The communication network can include all or part of the Internet, another communication network or a combination of communication networks. Information can be transmitted over the communication network in accordance with various protocols and standards, including Long Term Evolution (LTE), 5G, IEEE 802, Internet Protocol (IP) or other protocols or combinations of protocols. The communication network may transmit voice, video, biometric or authentication data or other information between connected computing devices.
[0126] [0126] Features described as separate embodiments can be implemented, in combination, in a single embodiment, while features described as a single embodiment can be implemented in multiple embodiments,
separately or in any suitable sub-combination.
Operations described and claimed in a specific order should not be understood as requiring the specific order, nor that all illustrated operations be performed (some operations may be optional). As appropriate, multitasking or parallel processing (or a combination of multitasking and parallel processing) can be performed.

权利要求:
Claims (11)
[1]
1. COMPUTER IMPLEMENTED METHOD performed by a consensus node to validate a transaction between a first node and a second node within a trusted protocol network (blockchain), characterized by the fact that the method comprises: receiving associated transaction data to the transaction, the transaction data comprising: data representing a plurality of assets, a first commitment that hides a first random number and a transaction transaction amount, a second commitment that hides a second random number, and a calculated change based on the deduction of the transaction value from a total value of the plurality of assets, the transaction value and a third random number both encrypted by a public key of the second node based on a linear deterministic homomorphic (HE) encryption scheme, the change and a fourth random number both encrypted by a public key of the first node based on linear deterministic HE scheme, a or more interval proofs, a proof of zero knowledge (ZKP) and a digital signature generated based on a private key that matches the public key of the first node; verify the digital signature based on the first node's public key; determine that the one or more interval proofs prove that the transaction amount and the change are each greater than or equal to zero; determine that the total value of the plurality of assets is equal to the sum of the transaction and change value; and determining, based on the ZKP, that the transaction is valid by determining that the first random number equals the third random number, the second random number equals the fourth random number, and the transaction value hidden in the first commitment is equal to the transaction value encrypted by the public key of the second node.
[2]
2. METHOD IMPLEMENTED BY COMPUTER, according to claim 1, characterized in that the transaction is carried out between an account associated with the first node and an account associated with the second node, and the method further comprises updating, after determining that the transaction is valid, the account associated with the first node and the account associated with the second node based on transaction value and change.
[3]
3. METHOD IMPLEMENTED BY COMPUTER, according to claim 1, characterized in that each of the plurality of assets is associated with one or more than one type of asset, a hidden asset value in a commitment and a random number used to generate the commitment.
[4]
4. METHOD IMPLEMENTED BY COMPUTER, according to claim 3, characterized in that it further comprises the determination that each of the plurality of assets is associated with the same type of asset.
[5]
5. COMPUTER IMPLEMENTED METHOD, according to claim 3, characterized in that the first commitment, the second commitment and the commitment that hides the asset value are generated based on a commitment scheme that is homomorphic and in which the determination that the total value of the plurality of assets is equal to the sum of the transaction value and the alteration is carried out based on the homomorphism of the commitment scheme.
[6]
6. METHOD IMPLEMENTED BY COMPUTER, according to claim 1, characterized by the fact that the linear deterministic HE scheme is derived from a probabilistic HE scheme based on changing a random number associated with the probabilistic HE scheme to a fixed number.
[7]
7. METHOD IMPLEMENTED BY COMPUTER, according to claim 1, characterized in that the ZKP comprises a compromise that hides a fifth random number and a sixth random number, a cyphertext (ciphertext) of the fifth random number and the sixth number random encrypted by the public key of the second account based on the linear deterministic HE scheme, and a cyphertext of the fifth random number and the sixth random number encrypted by the public key of the first account based on the linear deterministic HE scheme.
[8]
8. METHOD IMPLEMENTED BY COMPUTER, according to claim 1, characterized by the fact that the ZKP is generated and used to determine that the transaction is valid based on the properties of the linear deterministic HE.
[9]
9. METHOD IMPLEMENTED BY COMPUTER, according to claim 1, characterized in that the determination that the transaction is valid is performed based on the ZKP, without interactions between the first node and the second node through outside the network of trust protocol.
[10]
10. COMPUTER-READABLE STORAGE MEANS non-transient characterized by being coupled to one or more computers and configured with instructions executable by one or more computers to perform operations according to the method, as defined in one or more of claims 1 to 9.
[11]
11. SYSTEM, characterized by the fact that it comprises: one or more computers; and one or more computer readable memories coupled to one or more computers and configured with instructions executable by one or more computers for performing operations in accordance with the method as defined in one or more of claims 1 to 9.

类似技术:

---

公开号 | 公开日 | 专利标题

---

BR112019014629A2|2021-07-20|computer implemented method, computer readable storage medium and system

---

BR112019008160B1|2021-08-24|COMPUTER IMPLEMENTED METHOD EXECUTED BY A CONSENSUS NODE OF A BLOCK CHAIN NETWORK, COMPUTER-READABLE STORAGE MEDIA, AND SYSTEM TO IMPLEMENT A METHOD

---

BR112019016474A2|2021-06-29|computer implemented method, computer readable non-transient storage medium and system

---

BR112019008148B1|2021-08-10|METHOD IMPLEMENTED BY COMPUTER AND SYSTEM FOR IMPLEMENTING A METHOD

---

ES2876926T3|2021-11-15|Blockchain data protection using homomorphic encryption

同族专利:

---

公开号 | 公开日

---

US20190280880A1|2019-09-12|

---

US10790987B2|2020-09-29|

---

CN110402561B|2021-11-23|

---

ES2880458T3|2021-11-24|

---

WO2019072302A2|2019-04-18|

---

EP3560144B1|2021-05-05|

---

CN110402561A|2019-11-01|

---

US11063769B2|2021-07-13|

---

US20200366503A1|2020-11-19|

---

CA3050600A1|2019-04-18|

---

EP3560144A4|2020-03-04|

---

KR102193551B1|2020-12-23|

---

JP6808057B2|2021-01-06|

---

KR20200079217A|2020-07-02|

---

AU2018347202B2|2021-01-07|

---

SG11201906751YA|2019-08-27|

---

PH12019501716A1|2020-03-02|

---

AU2018347202A1|2020-07-09|

---

EP3560144A2|2019-10-30|

---

PL3560144T3|2021-10-25|

---

RU2733223C1|2020-09-30|

---

WO2019072302A3|2019-10-03|

---

MX2019008738A|2019-09-09|

---

CA3050600C|2020-11-17|

---

JP2020512572A|2020-04-23|

引用文献:

---

公开号 | 申请日 | 公开日 | 申请人 | 专利标题

---

---

US5394116A|1993-12-29|1995-02-28|At&T Corp.|Fractional phase shift ring oscillator arrangement|

---

IT1284718B1|1996-07-31|1998-05-21|Cselt Centro Studi Lab Telecom|DEVICE AND PROCEDURE FOR TEMPORARILY ALIGNING NUMERICAL SIGNALS, FOR EXAMPLE A CLOCK SIGNAL AND A FLOW OF DATA.|

---

FR2800220B1|1999-10-26|2002-02-15|France Telecom|SECURE ELECTRONIC TRANSACTION PROCESS|

---

US20090327141A1|2007-04-18|2009-12-31|Rabin Michael O|Highly efficient secrecy-preserving proofs of correctness of computation|

---

US20090177591A1|2007-10-30|2009-07-09|Christopher Thorpe|Zero-knowledge proofs in large trades|

---

US8667292B2|2011-05-19|2014-03-04|Microsoft Corporation|Privacy-preserving metering with low overhead|

---

EP2590126A1|2011-11-01|2013-05-08|Nederlandse Organisatie voor toegepast -natuurwetenschappelijk onderzoek TNO|Recommender system for providing recommendations to groups of users|

---

US8731199B2|2012-09-28|2014-05-20|Sap Ag|Zero knowledge proofs for arbitrary predicates over data|

---

AU2014290143C1|2013-07-15|2019-01-03|Visa International Service Association|Secure remote payment transaction processing|

---

US20150242825A1|2014-02-24|2015-08-27|Peter Burton Mills|Generation, storage, and validation of encrypted electronic currency|

---

WO2016076934A2|2014-08-22|2016-05-19|Thomas John K|Verification system for secure transmission in a distributed processing network|

---

WO2016049406A1|2014-09-26|2016-03-31|Technicolor Usa, Inc.|Method and apparatus for secure non-interactive threshold signatures|

---

US10257173B2|2014-10-22|2019-04-09|Openeye Scientific Software, Inc.|Secure comparison of information|

---

WO2016200885A1|2015-06-08|2016-12-15|Blockstream Corporation|Cryptographically concealing amounts transacted on a ledger while preserving a network's ability to verify the transaction|

---

RU2015145232A|2015-10-21|2017-05-03|Дмитрий Сергеевич Ермолаев|METHOD FOR ACCOUNTING AND STORAGE OF TEMPORARY ACCOUNTING UNITS IN SINGLE-LEVEL BLOCKCHAIN MEDIA|

---

US11042878B2|2016-01-19|2021-06-22|Priv8Pay, Inc.|Network node authentication|

---

US10846984B2|2016-02-24|2020-11-24|Uplay1|Casino crypto currency systems and methods|

---

US10046228B2|2016-05-02|2018-08-14|Bao Tran|Smart device|

---

US9635000B1|2016-05-25|2017-04-25|Sead Muftic|Blockchain identity management system based on public identities ledger|

---

CN107438002B|2016-05-27|2022-02-11|索尼公司|Block chain based system and electronic device and method in system|

---

JP6663809B2|2016-07-07|2020-03-13|株式会社日立製作所|Audit device, anonymous remittance method with audit function and program|

---

WO2018087836A1|2016-11-09|2018-05-17|株式会社日立製作所|Blockchain transaction system and blockchain transaction method|

---

CN106549749B|2016-12-06|2019-12-24|杭州趣链科技有限公司|Block chain privacy protection method based on addition homomorphic encryption|

---

US10243731B2|2017-01-27|2019-03-26|Accenture Global Solutions Limited|Hardware blockchain acceleration|

---

KR101879353B1|2017-01-31|2018-07-17|권양호|Mediation Service System and Method using Virtual Money|

---

US10832230B2|2017-04-04|2020-11-10|International Business Machines Corporation|Scalable and distributed shared ledger transaction management|

---

US10277395B2|2017-05-19|2019-04-30|International Business Machines Corporation|Cryptographic key-generation with application to data deduplication|

---

CN107274159A|2017-06-09|2017-10-20|北京泛融科技有限公司|A kind of accounting system and method that algorithm is concurrently performed based on block|

---

US10761877B2|2017-07-21|2020-09-01|Intel Corporation|Apparatuses, methods, and systems for blockchain transaction acceleration|

---

CN108418783B|2017-09-01|2021-03-19|矩阵元技术（深圳）有限公司|Method and medium for protecting privacy of intelligent contracts of block chains|

---

CN107656812A|2017-09-27|2018-02-02|咪咕文化科技有限公司|block chain processing method, system, node device, terminal and storage medium|

---

CN108021821A|2017-11-28|2018-05-11|北京航空航天大学|Multicenter block chain transaction intimacy protection system and method|

---

US10833861B2|2017-11-28|2020-11-10|International Business Machines Corporation|Protection of confidentiality, privacy and ownership assurance in a blockchain based decentralized identity management system|

---

CN108418689B|2017-11-30|2020-07-10|矩阵元技术（深圳）有限公司|Zero-knowledge proof method and medium suitable for block chain privacy protection|

---

WO2019109003A1|2017-11-30|2019-06-06|Visa International Service Association|Blockchain system for confidential and anonymous smart contracts|

---

EP3741082B1|2018-01-19|2021-12-29|Qed-It Systems Ltd.|Proof chaining and decomposition|

---

US20190229921A1|2018-01-22|2019-07-25|Allen Pulsifer|Private Multi-Secret Cryptographic Transaction System|

---

EP3522064B1|2018-02-02|2021-12-22|Università Degli Studi Di Trento|A method and apparatus for distributed, privacy-preserving and integrity-preserving exchange, inventory and order book|

---

US20190251527A1|2018-02-14|2019-08-15|Christopher Walter Surdak|System, Method, and Computer Program Product for a Distributed, Cryptographically Secured Proof-of-Intent Transaction Network|

---

CN108764874B|2018-05-17|2021-09-07|深圳前海微众银行股份有限公司|Anonymous transfer method, system and storage medium based on block chain|

---

CN108985933A|2018-06-29|2018-12-11|联动优势科技有限公司|A kind of bookkeeping methods and device|

---

CN109035029A|2018-07-27|2018-12-18|阿里巴巴集团控股有限公司|Based on the assets transfer method and device of block chain, electronic equipment|

---

CN109039648B|2018-08-03|2021-09-03|克洛斯比尔有限公司|Block chain creating method and device and readable storage medium|

---

ES2876926T3|2018-11-07|2021-11-15|Advanced New Technologies Co Ltd|Blockchain data protection using homomorphic encryption|

---

MX2019009412A|2018-12-21|2019-10-02|Alibaba Group Holding Ltd|Blockchain data protection based on generic account model and homomorphic encryption.|US20180212753A1|2017-01-20|2018-07-26|Enveil, Inc.|End-To-End Secure Operations Using a Query Vector|

---

US10693627B2|2017-01-20|2020-06-23|Enveil, Inc.|Systems and methods for efficient fixed-base multi-precision exponentiation|

---

US11196541B2|2017-01-20|2021-12-07|Enveil, Inc.|Secure machine learning analytics using homomorphic encryption|

---

US10771237B2|2017-01-20|2020-09-08|Enveil, Inc.|Secure analytics using an encrypted analytics matrix|

---

CN111783114A|2018-08-06|2020-10-16|阿里巴巴集团控股有限公司|Block chain transaction method and device and electronic equipment|

---

US10902133B2|2018-10-25|2021-01-26|Enveil, Inc.|Computational operations in enclave computing environments|

---

US10817262B2|2018-11-08|2020-10-27|Enveil, Inc.|Reduced and pipelined hardware architecture for Montgomery Modular Multiplication|

---

MX2019009412A|2018-12-21|2019-10-02|Alibaba Group Holding Ltd|Blockchain data protection based on generic account model and homomorphic encryption.|

---

US10795644B2|2019-01-08|2020-10-06|Moac Blockchain Tech Inc|Decentralized random number generator|

---

US10790990B2|2019-06-26|2020-09-29|Alibaba Group Holding Limited|Ring signature-based anonymous transaction|

---

CN112488703A|2019-06-26|2021-03-12|创新先进技术有限公司|Anonymous transaction method and device based on ring signature|

---

CN110839028A|2019-11-14|2020-02-25|南京邮电大学|Privacy protection method for fog-assisted industrial Internet of things|

---

CN110991655B|2019-12-17|2021-04-02|支付宝信息技术有限公司|Method and device for processing model data by combining multiple parties|

---

CN111401875B|2020-05-29|2020-09-01|支付宝信息技术有限公司|Block chain transfer method and device based on account model|

---

CN112910933B|2021-05-07|2021-07-13|鹏城实验室|Authentication method, authentication device, and verification device|

法律状态:
2021-08-03| B25B| Requested transfer of rights rejected|Owner name: ADVANCED NEW TECHNOLOGIES CO., LTD. (KY) Free format text: INDEFERIDO O PEDIDO DE TRANSFERENCIA CONTIDO NA PETICAO 870200160217 DE 22/12/2020, EM VIRTUDE DO PEDIDO JA ESTAR EM NOME DO INTERESSADO. |

---

2021-08-17| B25B| Requested transfer of rights rejected|Owner name: ADVANCED NEW TECHNOLOGIES CO., LTD. (KY) Free format text: INDEFERIDO O PEDIDO DE TRANSFERENCIA CONTIDO NA PETICAO 870200160603 DE 23/12/2020, EM VIRTUDE DO PEDIDO JA ESTAR EM NOME DO INTERESSADO. |

优先权:

---

申请号 | 申请日 | 专利标题

---

PCT/CN2018/122573|WO2019072302A2|2018-12-21|2018-12-21|Blockchain data protection based on generic account model and homomorphic encryption|

---